前言

昨天我們請 Claude 老兄 幫我們快速找到了：

👉 當使用者進入產品頁時，後端程式碼的主要 Controller：

vendor/magento/module-catalog/Controller/Product/View.php而它的進入點正是execute()方法。

.
.
不過 Controller 本身並不處理太多資料邏輯，它只是一個 「流程協調者」。
所以今天，我們就要更深入一步，看看 Controller 在收到 使用者需求 之後，程式是怎麼把產品資料透過Model載入回來的。

.
.

在 Magento 裡，傳統 MVC 的 Model 會再拆成三個角色：
Repository → Model → ResourceModel。
接下來就沿著這三層，把資料怎麼流動跑一遍。

ℹ️ 小註解｜為什麼Model要區分成Model、Repository、Resource Model？

在大型、可擴充的框架裡（像 Java 的 Spring/.NET、電商平台如 Magento、Shopware），很常把 Model 拆成各自的層（Model／Repository／Resource）。這種分工讓每層只專注一件事：規則可以獨立演進，資料層能自由調整查詢與快取策略，對外 API 也保持穩定。當系統面對 EAV、多商店、多語系或高併發時，這樣的拆分能把複雜度關在該在的地方，整體更好維護與測試。

.
.
.

先釐清三個角色：Model / Repository / ResourceModel

先用一個餐廳比喻記起來：

Controller 像服務生（接單） →
Repository 像出餐口（統一拿餐） →
Model 像餐點本身（有規格/口味/價格等邏輯） →
ResourceModel 像廚房（真的下廚、跟冰箱拿料＝查資料庫）

.

🍜 例子：點一碗「叉燒拉麵」

• 使用者說：「我要 叉燒拉麵，加辣、加麵。」
• Controller（服務生）：把需求整理好 →「拉麵 #123，需要加辣、加麵」。
• Repository（出餐口）：負責統一拿餐 →「我要 #123 的餐點」。
• ResourceModel（廚房）：真的去**冰箱／倉庫（資料庫/EAV 表）**拿料，組合好：
  • 主表：catalog_product_entity（餐點基本身份）
  • 配料表：catalog_product_entity_varchar/int/decimal/...（口味、大小、價格等屬性）
  • 把這些值拼起來，交回餐點本體
• Model（餐點本體）：回到出餐口時，這碗拉麵已經有「名稱、價格、可選規格」等行為與屬性，接著可以：
  • 判斷型別（simple/configurable/…）
  • 計算售價／選項提示（例如：「請先選擇大小」）
  • 提供方法讓頁面取用（getName(), getPrice() …）

.
.

🧱 Model（領域物件）

• 代表「一個產品」本身的資料與行為：Magento\\Catalog\\Model\\Product
• 封裝商業邏輯（例如型別行為、價格計算、屬性存取）
• 不直接打資料庫（不負責 IO）

🗄️ ResourceModel（資料庫 IO）

• 負責真的和 DB 溝通：Magento\\Catalog\\Model\\ResourceModel\\Product
• 定義主表/主鍵，執行 CRUD 與 EAV 屬性拼裝

🔌 Repository（對外入口 / 服務契約）

• 建議的取用方式：Magento\Catalog\Api\ProductRepositoryInterface
• 提供 getById / get / save / delete 等 API

彼此關係（一句話）

Controller 不打 DB → 透過 Repository 取得 Model → 背後由 ResourceModel 真的去查資料（含 EAV）。

.
.

從 execute() 開始看：Controller 做了什麼？

在前言我們提到，Controller 比較像是流程協調者。那實際上它協調了什麼？

讓我們從 Controller 接收到使用者請求後，進入 execute() 開始看起。

1) 關鍵一步：初始化產品

$product = $this->_initProduct();

這一行是重頭戲。它代表：

• 現在要取得產品資料了，但 Controller 不會自己查資料庫（那不是它的職責）。

• 這個呼叫會把流程往 Model 端推進，背後實際會走到：

  Repository → Model → ResourceModel（打 DB / EAV）

換句話說：Controller 只是「服務生接單」，真正「下廚拿菜」的是 Model 這一側。

.
.

2) 請 Claude 快速整理Model（從 _initProduct() 往下）

這裡我們延續昨天的做法，請 Claude 老兄 先把「從 _initProduct() 往下」的路徑梳理成可讀的文件，去了解實際會經過哪些類別與方法、資料究竟在哪一站被載入，這邊我們prompt下：

請幫我詳細分析Controller用了
$product = $this->_initProduct();
時，詳細的程式流程，讓我詳細了解MVC中的Model
並將內容寫在『產品頁Model分析.md』中

一樣不到3分鐘便得到了claude的整理：

到這裡，我們已經把呼叫鏈、關鍵類別與檔案位置都對齊了。
從圖上可以清楚看到今天的主軸就是：
Repository → Model → ResourceModel

註：中間的 Helper 暫時視為「橋接／渲染前準備站」，本篇先不展開。

.
.

這裡是 Claude 幫我們整理的檔案位置（搭配 IDE 開檔對照最有感）：

• vendor/magento/module-catalog/Model/ProductRepository.php
• vendor/magento/module-catalog/Model/Product.php
• vendor/magento/module-catalog/Model/ResourceModel/Product.php

有了這個清單，我們就能沿著檔案一路看下去，搞清楚 各個層（Repository / Model / ResourceModel）各自負責什麼。

.
.

--

結語

今天用 Claude 老兄 把 Repository → Model → ResourceModel 的路徑先梳成地圖，重點放在概念與心法。
.
.
受限於篇幅，這裡只做淺略介紹；
.
.
更細部的呼叫鏈、事件／Plugin 插點與 EAV 細節，礙於篇幅本文僅作概念與心法導讀；建議直接閱讀原始碼與設定檔（如 ProductRepository.php、Product.php、ResourceModel/Product.php、di.xml、events.xml、catalog_product_view.xml）來深化理解。你也可以搭配 Claude 一起深挖細節。
.
.
明天換 View 登場：Layout XML → Block → PHTML，看資料怎麼被組裝成產品頁